calljdku912fandomcom-20200214-history
Aggregator *Parvaneh Moradi)
Aggregators What are aggregators? Aggregators enable global computation in your application. You can use them, for example, to check whether a global condition is satisfied or to keep some statistics. During a super step, vertices provide values to aggregators. These values get aggregated by the system and the results become available to all vertices in the following superstep. Providing a value to aggregator is done by calling: aggregate(aggregator Name, aggregated Value) and to get the value aggregated during previous super step you should call: getAggregatedValue(aggregator Name) Aggregator operations should be commutative and associative since there is no guaranteed ordering in which the aggregations will be performed. Regular vs persistent aggregator Aggregators come in two flavors: regular and persistent aggregators. The value of a regular aggregator will be reset to the initial value in each super step, whereas the value of persistent aggregator will live through the application. As an example, consider Long Sum Aggregator being used by each vertex adding 1 to it during compute(). If this is a regular aggregator, you'll be able to read the number of vertices in the previous super step from it. If this is persistent aggregator, it will hold the sum of the number of vertices from all of the previous super steps. Registering aggregators Before using any aggregator, you MUST register it on the master. You can do this by extending (and setting) Master Compute class, and calling: Register Aggregator(aggregator Name, aggregator Class) or: register Persistent Aggregator(aggregator Name, aggregator Class) depending on what kind of aggregator you want to have. You can register aggregators either in Master Compute. initialize() - in that case the registered aggregator will be available through whole application, or you can do it in Master Compute. compute() - the aggregator will then be available in current and each of the following super steps. Aggregators and Master Compute The first thing that gets executed in a super step is Master Compute. compute(). In this method you are able to read aggregated values from previous super step by calling: Get Aggregated Value(aggregator Name) and you are able to change the value of the aggregator by calling: set Aggregated Value(aggregator Name, aggregated Value) Implementations In the package org. apache. Graph. Aggregators you can find many common aggregators already implemented. If you need to create your own, you can extend Basic Aggregator or implement Aggregator. Methods which you will need to implement are: aggregate(value) which describes how to add another value to the aggregator, and: createInitialValue() The initial value will be applied to all aggregator objects when they are created. When it's added to an aggregator the value of the aggregator shouldn't change. For example, for sum aggregator this value should be zero, for min aggregator it should be the value corresponding to positive infinity, etc. If you need some parameters from the configuration in your aggregators, your aggregator class can implement Immutable Classes Giraph Configurable. Advanced options If you are using multiple threads for computation (giraph.numComputeThreads), you should consider turning on giraph.useThreadLocalAggregators option. Using thread local aggregators allows every worker thread to have it's own local aggregator copy, rather than a single aggregator copy for the entire worker. The downside of this approach is that it will use more memory - you'll have several copies of each of the aggregators. So if you have a lot of aggregators, or aggregated values are very large objects, this option could be bad. But otherwise, it will likely speed up your application since it will remove the need to perform synchronization when aggregating values. Implementation details During a superstep, values provided to the aggregators are being aggregated to some worker-local aggregator objects. In the end of the superstep, all of these values need to be aggregated together, given to the master, and after MasterCompute.compute is performed, distributed back to all the workers. In applications which use a lot of aggregators, if all the aggregations were to be done on master, this could cause a serious bottleneck, both from the computation and network communication standpoint, because master would be receiving, processing and sending (number of workers * total size of aggregators) amount of data. This was the motivation for implementing sharded aggregators in Giraph. In the end of the superstep, each aggregator is assigned to one of the workers, and that worker receives and aggregates values for that aggregator from all other workers. Then worker sends all its aggregators to master, so master doesn't have to perform any aggregation, and receives only final value for each of the aggregators. After MasterCompute.compute, master doesn't do the distribution of all aggregators to all workers, but aggregators again have their owners. Master only sends each aggregator to its owner, and then each worker distributes the aggregators which it owns to all other workers.